Distributed processing networks are being increasingly used for live voice communications between network nodes using Voice over IP or VoIP technology. Distributed processing networks are typically designed to provide a quality of service described as Best Effort or BE that does not discriminate between services and does not control service access or quality. Voice telephony depends upon reliable, low latency, real-time delivery of audio data that BE-based networks cannot consistently provide. To emulate the high quality of service offered by traditional circuit-switched voice telephony networks, the IEFT has published RFC 2205, namely the Resource Reservation Protocol or RSVP, which signals an application's quality of service requirements to the data network over which packets are sent. RSVP allows an endpoint to negotiate with an RSVP-capable network to allocate protected resources for traffic flow that the endpoint will generate. RSVP thereby is able to provide a guaranteed quality of service for a VoIP session.
An illustration of the operation of the RSVP protocol is depicted in FIG. 1. The sender 100 who is initiating the VoIP communication initially sends a path request message addressed to the receiver 104. The path request message or path message conveys the requested traffic specification to all RSVP-aware network nodes on the path and to the receiver. Each RSVP-aware router 108 and 112 in the path 116 between the sender 100 and receiver 104 makes a soft reservation (which will time out if it is not used), establishes a record of the previous RSVP aware node the path message came from, and composes information relating to the quality of service (QoS) characteristics (e.g., minimum supported MTU size, minimum supported bandwidth, and minimum path latency) that it is able to offer. When received, the receiver 104 examines the path message and the gathered path data before deciding to make a reservation. When the reservation is acceptable, the receiver 104 transmits a reservation or Resv message to install the reservation at each router 108 and 112 on the path. The resv message is relayed hop-by-hop in reverse order that the path message took back to the sender 100. Each router 108 and 112 verifies through admission control that the reservation may be installed. In response to the resv message, the sender 100 sends a path tear message that tears down existing reservations at all intermediate nodes in the path, namely routers 108 and 112, to construct the communication path between the sender 100 and the receiver 104. As will be appreciated, synchronized RSVP reservations are uni-directional and reservations are set in both the forward and reverse directions. The forward and reverse reservation routes can traverse different sets of routing nodes.
A problem with VoIP technology is that the technology does not have the reliability of circuit-switched telephony in guaranteeing the availability of network resources for specific types of calls. For example, a caller dialing an emergency number (in the U.S. the emergency number is 911 and in Australia 000) over a VoIP network can encounter a number of obstacles. First, some VoIP networks establish calls regardless of the success of an RSVP path or reservation request. In such networks, the call may be placed but the RSVP capable network may not be able to allocate protected bandwidth for the call. Audio quality under these circumstances may be so poor that the emergency caller and Public Safety Access Point or PSAP cannot communicate with the caller. In this scenario, the emergency call is placed so that the PSAP is aware of an emergency but information about the type and nature of the emergency cannot be communicated. Second, some VoIP networks may not allow calls to proceed if the RSVP path or reservation requests fail. The call may be rejected by the RSVP network to protect existing RSVP-protected traffic resulting in an emergency call being prevented by a lack of network resources. In this scenario, the call cannot be placed, and the PSAP is unaware of the emergency.
Another problem with VoIP technology is that it is difficult at best to determine the geographic location of the emergency caller. The Federal Communications Commission is requiring mandatory location accuracy for various types of communication devices, such as VoIP devices, placing 911 calls. Knowing the electronic address of the emergency caller on the data network typically does not provide the physical location of the caller. Moreover, when VoIP communications are interrupted due to the condition of the caller and/or VoIP network the caller may have been unable to provide relevant information, such as in medical emergencies.
Other standardized services such as differentiated services (Diffserv) and virtual network segmentation (VLANs) can also be used to provide a guaranteed quality of service. These are specified in standard 802.1p/Q. Differentiated services allow for packets to be handled in a differentiated manner, thus allowing packets to be handled in different queues and allowing one type of service (TOS) priority over another. Unfortunately, the standardized serves do not provide for an “emergency” designation and the service type of similar services (for example VoIP calls) could be the same where one call should have precedence over another (a 911 call reporting a fire versus a call to recall last night's basketball game). VLANs allow traffic from a single endpoint to be handled as if it originated from multiple virtual endpoints. VLANS, however, do not indicate the precedence or relative priority of the “call” or traffic.
In telephony networks, MLPP (Multi Level Pre-emption Protocol or Multi-Level Precedence Protocol) provides a preemption method for signaled channelized circuit switched interfaces (ISDN). MLPP is used widely in military networks. Before ISDN interfaces had this capability, precedence was indicated in band for down stream switches to act on. Networks handling this approach are called “autovon” networks. These technologies however only apply to channelized networks and not packet networks. A preemption method has not been developed for packet-switched networks because in packet-switched networks no channels can be identified and dealt with as a permanent resource.